Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@portals/admin/src/main/webapp/source/src/app/components/GatewayEnvironments/AddEditGWEnvironment.jsx`:
- Around line 337-341: The added UI and alert strings in
AddEditGWEnvironment.jsx (e.g., the Alert.success/Alert.error messages like
"Gateway registration token regenerated successfully." and "Failed to regenerate
gateway registration token.", and other texts such as "Loading gateway
details...", "Back to Gateways", "Gateway Name", "Generate Key") are hardcoded
English; replace each hardcoded literal with the project's localization API
(e.g., use intl.formatMessage, t(), or the existing i18n helper used elsewhere
in the codebase) and reference appropriate message IDs from the locale bundles
added in this PR; update the Alert.success and Alert.error calls to pass
localized strings instead of raw literals, and ensure all other occurrences in
the file (ranges noted around the diff and lines ~363-364, 404-408, 816-1086)
are converted to use the same localization mechanism so the page respects the
locale bundles.
- Around line 367-400: The call to updateGatewayEnvironment in
AddEditGWEnvironment.jsx omits the provider argument so it falls back to the
default ('wso2') and can overwrite api-platform environments; when performing
header-only saves preserve the existing provider value used in formSaveCallback
by passing the provider through to updateGatewayEnvironment (or by reading it
from the current environment object) so the provider is included after the other
DTOs (additionalPropertiesArrayDTO, permissionsDTO, vhostDTO) in the argument
list; ensure the same provider symbol/name used in formSaveCallback is used here
so provider is not lost on save.

In
`@portals/admin/src/main/webapp/source/src/app/components/GatewayEnvironments/ListGWEnviornments.jsx`:
- Around line 101-112: The code currently defaults gatewayStatus to 'Active' and
only overwrites it for platform gateways, causing non-platform rows to
incorrectly show a green "Active" chip; change the logic in
ListGWEnviornments.jsx so gatewayStatus starts as null/undefined and is assigned
only when additionalProperties.isActive is explicitly present (e.g., set
gatewayStatus = additionalProperties.isActive === 'true' ? 'Active' : 'Inactive'
only for entries that expose that field), keep the raw nullable value in the
returned object (retain id, isPlatformGateway, gatewayTypeDisplay) and ensure
the UI rendering only shows the status chip when gatewayStatus is non-null;
apply the same fix to the other similar blocks referenced (around the other
ranges 172-181 and 254-263).
- Around line 60-83: The click handler in GatewayEditButton currently falls back
to dataRow.id when building the platform-gateway route; remove that fallback so
we only navigate to /settings/environments/platform-gateways/:id when
additionalProperties.platformGatewayId exists. In handleClick (and the second
identical block around lines 97-110), call
getAdditionalPropertiesAsMap(dataRow.additionalProperties), read
platformGatewayId without defaulting to dataRow.id, and if platformGatewayId
push the platform-gateways path, otherwise push the regular environment edit
path (/settings/environments/{dataRow.id}); update both occurrences of this
logic in GatewayEditButton to ensure consistent routing.

In `@portals/admin/src/main/webapp/source/src/app/data/api.js`:
- Around line 1185-1237: Add the missing requestContentType to the two gateway
methods: in getPlatformGatewayList() and deletePlatformGateway(gatewayId) ensure
the object passed to client.execute includes requestContentType:
'application/json' (same as createPlatformGateway() and
regeneratePlatformGatewayToken()), i.e., update the client.execute call inside
both getPlatformGatewayList and deletePlatformGateway to include
requestContentType: 'application/json'.

In `@portals/publisher/src/main/webapp/site/public/conf/settings.json`:
- Line 53: Update the supportedApiTypes array in settings.json so it includes
the three missing API types used by the codebase constants: add "WEBSUB",
"WEBHOOK", and "ASYNC" to the existing array in the settings.json file (the
supportedApiTypes entry) so it matches the full set of API types used by the
policy filtering logic.
- Around line 50-54: The policyHub configuration in settings.json contains a
hardcoded development URL in the "policyHub.endpoint" value; replace this with
an environment-specific mechanism (e.g., read process env like
POLICY_HUB_ENDPOINT at startup or use environment-specific files such as
settings.prod.json/settings.dev.json) and ensure whatever config loader the app
uses reads that env var or loads the correct file before enabling the
"policyHub" feature; update any deployment docs to require setting
POLICY_HUB_ENDPOINT (or including settings.prod.json) and change uses of
policyHub.endpoint to the resolved runtime value.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/CreateAPIWithAI/APICreateWithAI.jsx`:
- Around line 93-97: The gatewayDetails map currently only contains the
'platform-gateway' key which causes lookups from settings.environment (where
gatewayType may be 'PlatformGateway') to miss and create a custom gateway;
update the gatewayDetails map (the object named gatewayDetails in
APICreateWithAI.jsx) to also include a 'PlatformGateway' entry mapping to the
same value/name/description as 'platform-gateway' or normalize the gatewayType
value (e.g., lowercase/slugify) before performing the lookup in the code that
reads settings.environment; apply the same change or normalization in
APICreateRoutes.jsx where a similar lookup occurs (around the lookup at line 77)
so both components resolve the Platform Gateway identifier consistently.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/AttachedPolicyCard.tsx`:
- Around line 64-65: The code currently sets isPolicyHubGatewayPolicy from
policyObj.supportedGateways
(policyObj.supportedGateways?.includes(CONSTS.GATEWAY_TYPE.apiPlatform)) which
checks capability metadata instead of the active API gateway; change the logic
to derive the flag from the current API's gatewayType (use the same field used
by the drawer, e.g., api.gatewayType or the API prop available in
AttachedPolicyCard) and update both occurrences (the isPolicyHubGatewayPolicy
declaration and the identical check at the later location around line 157) so
showDownload and related behavior use the actual API gateway (compare
api.gatewayType === CONSTS.GATEWAY_TYPE.apiPlatform) rather than
policyObj.supportedGateways.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/Policies.tsx`:
- Around line 241-242: The else-if branch setting gatewayType =
CONSTS.GATEWAY_TYPE.apiPlatform is unreachable because isPolicyHubGateway is
returned early; remove this dead branch from the Policies component logic (look
for the isPolicyHubGateway check and the gatewayType assignment near the current
conditional) or refactor the surrounding conditional so gatewayType
determination is mutually exclusive and consistent with isPolicyHubGateway
(update any code that reads gatewayType accordingly).

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PoliciesExpansion.tsx`:
- Around line 111-119: The current lookup in PoliciesExpansion.tsx only calls
PolicyHub.getPolicySpec when both policyName and policyVersion exist, causing
attachments with a missing ApiPolicy.policyVersion to be dropped; update the
logic to attempt a lookup by name alone when policyVersion is missing (call
PolicyHub.getPolicySpec with { name: policyName, displayName: policyName } or
similar) and if that still yields null, create and return a minimal placeholder
policy object (with name/displayName and a flag like isPlaceholder) so the
attachment remains visible in allPolicies/flow rendering; ensure you update any
callers that rely on version to handle the placeholder case.
- Around line 122-128: The fallback in PoliciesExpansion.tsx always calls
API.getOperationPolicy(...) which prevents resolving attached common policies;
update the logic to call API.getCommonOperationPolicy(...) when the policy is
known to originate from common policies (use the same flag name isCommonPolicy
used by callers that populate originatedFromCommonPolicies). Modify the call
sites that push into originatedFromCommonPolicies to pass isCommonPolicy through
to the place that resolves the policy, and inside PoliciesExpansion (the
function that currently calls API.getOperationPolicy and returns
policyResponse?.body) choose API.getCommonOperationPolicy(policyId, api.id) when
isCommonPolicy is true, otherwise keep API.getOperationPolicy; ensure the
resolved body handling remains the same.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyConfigurationEditDrawer.tsx`:
- Around line 104-116: When loading the policy spec in
PolicyConfigurationEditDrawer (inside the isPolicyHubGateway branch where
PolicyHub.getPolicySpec is called), ensure you fall back to
PolicyHub.toPolicySpec(policyObj) if PolicyHub.getPolicySpec(...) returns
undefined/null; i.e., after awaiting PolicyHub.getPolicySpec({ name:
policyObj.name, version: policyObj.version, displayName: policyObj.displayName
}) assign policySpecVal = result ?? PolicyHub.toPolicySpec(policyObj) so
migrated/deleted policies render, matching the behavior in ViewPolicy.tsx.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyForm/GeneralDetails.tsx`:
- Around line 271-299: The TextField for the description in GeneralDetails.tsx
incorrectly reuses id='name', causing duplicate DOM ids; update the TextField's
id to a unique value (e.g., 'description') so it matches the name/data-testid
and preserves proper label association and accessibility; ensure the change is
applied on the TextField with props value={description},
onChange={handleInputChange} and inputProps referencing isViewMode so behavior
remains unchanged.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyForm/SourceDetails.tsx`:
- Around line 89-90: supportedGateways can be undefined, so first normalize it
(e.g., const normalizedSupportedGateways = Array.isArray(supportedGateways) ?
supportedGateways : []) and then replace usages of
supportedGateways.includes(...) with normalizedSupportedGateways.includes(...);
specifically update the computation of isPolicyHubGatewayPolicy (currently using
supportedGateways.includes(CONSTS.GATEWAY_TYPE.apiPlatform)) and reuse
normalizedSupportedGateways for the later checks referenced in this component
(the other .includes calls around Lines 94 and 257).

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyList.tsx`:
- Around line 223-227: The renderValue callback in PolicyList (the
renderValue={(selected) => ...} block) returns a hardcoded 'All' string; replace
that literal with an i18n lookup by importing and using useIntl in the
PolicyList component and calling intl.formatMessage({ id:
'Apis.Details.Policies.All', defaultMessage: 'All' }) (or use <FormattedMessage
/> equivalent) so the fallback text is internationalized; ensure useIntl is
invoked in the component and the renderValue path uses intl.formatMessage
instead of the hardcoded 'All'.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/ViewPolicy.tsx`:
- Around line 60-80: When starting the Policy Hub fetch inside the dialogOpen &&
isPolicyHubGateway branch, clear any stale policySpec up front by calling
setPolicySpec(undefined) (or the empty initial state) before setLoading(true)
and PolicyHub.getPolicySpec; then in the .catch handler,
setPolicySpec(PolicyHub.toPolicySpec(policyObj)) as the local fallback instead
of leaving the previous spec, and keep Alert.error for the user-facing
message—this ensures PolicyHub.getPolicySpec (and functions
PolicyHub.getPolicySpec, PolicyHub.toPolicySpec, setPolicySpec, setLoading,
Alert.error) cannot leave stale data displayed if the fetch fails.

In `@portals/publisher/src/main/webapp/source/src/app/data/Constants.js`:
- Around line 85-89: The project uses two different serialized identifiers for
the same gateway ('platform-gateway' vs the new CONSTS.GATEWAY_TYPE.apiPlatform
= 'api-platform'), causing policy flows to miss APIs; update APICreateRoutes.jsx
(the publisher create flow) and MetaData.jsx (the special-case logic) to emit
and check CONSTS.GATEWAY_TYPE.apiPlatform instead of the literal
'platform-gateway', and update PoliciesExpansion.tsx and PolicyViewForm.tsx to
also accept a fallback for existing records (treat 'platform-gateway' equivalent
to CONSTS.GATEWAY_TYPE.apiPlatform) so both new and existing APIs map to the
same Policy Hub path.

---

Nitpick comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyList.tsx`:
- Around line 124-153: The effect reads selectedCategories but doesn't include
it in dependencies, risking stale closures and ESLint warnings; update the logic
in the useEffect (the useEffect that references availableCategories, isAIAPI,
isRestAPI, selectedCategories, and calls setSelectedCategories) to use a
functional state update: call setSelectedCategories(prev => { compute
normalizedSelection, nextSelection and compare against prev, returning prev or
the new array }) so the current selectedCategories value is read from prev
instead of the closed-over variable; alternatively, if you prefer not to use a
functional updater, add selectedCategories to the dependency array of the
useEffect to satisfy exhaustive-deps.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@portals/admin/src/main/webapp/site/public/locales/fr.json`:
- Line 160: Several locale entries in the French locale are still in English;
update the keys such as "AdminPages.Gateways.table.header.gatewayStatus" and the
other untranslated keys referenced (around the other ranges) with proper French
translations, e.g., replace the English strings with their French equivalents
for all entries in fr.json (including the blocks around the reported offsets 382
and 509-536); ensure you only change the string values (keep the JSON keys
intact), validate the JSON, and run a quick UI spot-check of the gateway screens
to confirm translations render correctly.

In
`@portals/admin/src/main/webapp/source/src/app/components/GatewayEnvironments/AddEditGWEnvironment.jsx`:
- Around line 221-236: The fallback platform-gateway object sets no isActive but
downstream rendering treats falsy as "Inactive"; update the fallback created in
the platformGateway lookup (where platformGatewayId is used and
setPlatformGateway is called) to include isActive: null (or undefined) instead
of leaving it ambiguous so the header can render an explicit "Unknown" or hide
the chip; make the same change for the other similar fallback creation (the
other setPlatformGateway call referenced in the diff) so unresolved gateways
have a nullable isActive rather than being interpreted as inactive.

In
`@portals/admin/src/main/webapp/source/src/app/components/GatewayEnvironments/ListGWEnviornments.jsx`:
- Around line 93-109: The row mapping currently sets human-readable English
strings into gatewayTypeDisplay and gatewayStatus (e.g., 'Platform Gateway',
'Active', 'Inactive'); instead, keep raw values in the model so the renderer can
localize with intl.formatMessage: set gatewayTypeDisplay to a stable token/enum
(e.g., item.gatewayType or 'platform' for platform gateways) and set
gatewayStatus to a raw status flag (e.g., additionalProperties.isActive as
boolean or 'true'/'false' or a constant like 'ACTIVE'/'INACTIVE'), remove
hard-coded English text from the map block inside the
environmentResult.body.list .map (refer to the isPlatformGateway,
platformGatewayId, gatewayTypeDisplay and gatewayStatus symbols) and apply the
same change for the other mapping at 170-181 so the UI renderer can call
intl.formatMessage() to produce localized labels.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyForm/GeneralDetails.tsx`:
- Around line 98-104: Update the static section summary text in GeneralDetails
so it respects the hideFlowsAndApiTypes flag: when hideFlowsAndApiTypes is true,
replace or neutralize the sentence that prompts users to "provide applicable
flows" (or similar) and instead show copy that does not reference Applicable
Flows or Supported API Types; use the existing booleans showApplicableFlows /
showSupportedApiTypes (or directly hideFlowsAndApiTypes) to decide which copy to
render so the summary matches the visible fields.

---

Nitpick comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyList.tsx`:
- Around line 169-170: Add a clarifying comment above the shouldShowPolicy
function explaining that an empty selectedCategories array is treated as "show
all" (i.e., selectedCategories.length === 0 returns true), so the function
returns true for all policies when nothing is selected; reference the function
name shouldShowPolicy and the helper getPolicyCategory so reviewers can locate
and understand the intent.
- Around line 125-154: Add a short inline comment inside the useEffect above the
default-selection block explaining the intent and rules for default categories:
that when availableCategories is non-empty we filter invalid selections and, if
nothing remains, we pick API-type-specific defaults (for isAIAPI choose
['AI','Guardrails'], for isRestAPI choose ['Transformation','Security']) only if
those defaults are present in availableCategories—this comment should be placed
near the setSelectedCategories callback (referencing useEffect,
setSelectedCategories, availableCategories, isAIAPI, isRestAPI) so future
maintainers understand the fallback/default logic without changing any behavior.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/ViewPolicy.tsx`:
- Line 124: The useEffect in ViewPolicy currently depends only on dialogOpen but
also reads isPolicyHubGateway (derived from api.gatewayType), so add
isPolicyHubGateway to the dependency array so the effect re-runs when
api.gatewayType changes; locate the useEffect that references dialogOpen and
isPolicyHubGateway and include isPolicyHubGateway (or the underlying
api.gatewayType) in its dependency list to ensure the branch logic updates
correctly while the dialog is open.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@portals/admin/src/main/webapp/source/src/app/components/GatewayEnvironments/PlatformGatewayManagement.jsx`:
- Around line 634-655: The async handlers (handleRoleAddition and similarly
handleRoleDeletion) suffer from stale closure updates on
validRoles/invalidRoles; change all state updates inside their promise
resolution/rejection to use functional state setters (e.g., setValidRoles(prev
=> [...prev, role]) and setInvalidRoles(prev => [...prev, role]) and compute
roleValidity from the current prev values) so each async callback operates on
the latest state rather than captured arrays; update every setValidRoles,
setInvalidRoles and setRoleValidity call in handleRoleAddition (and mirror the
pattern in handleRoleDeletion) to use the functional updater form and derive
roleValidity from the up-to-date prev state.

In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyForm/GeneralDetails.tsx`:
- Around line 163-166: The handler handleApiTypeChange currently references
isWebsocketSelected before it's declared, causing a temporal dead zone error;
move the declaration/initialization of the isWebsocketSelected variable so it
appears above (or at least before) the handleApiTypeChange function definition,
then update any other usages (e.g., the similar block around lines 175-178) to
reference the already-initialized isWebsocketSelected; ensure
handleApiTypeChange and any related logic read the variable only after it's
defined.

In `@portals/publisher/src/main/webapp/source/src/app/data/PolicyHub.js`:
- Around line 31-40: parsePolicyId fails when the policy name contains
POLICY_ID_SEPARATOR because splitting on the separator yields >2 parts; update
parsePolicyId to locate the last occurrence of POLICY_ID_SEPARATOR (e.g., via
lastIndexOf) and split into name = substring before that index and version =
substring after, preserving any separators in the name, then validate non-empty
name/version and return {name, version} or null; reference the parsePolicyId
function and POLICY_ID_SEPARATOR when making the change.

---

Nitpick comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Policies/PolicyList.tsx`:
- Around line 174-180: filterPoliciesForFlow is being run repeatedly during
render; wrap the filtered results in useMemo so the arrays are recomputed only
when inputs change. Replace repeated calls to filterPoliciesForFlow for each
flow (e.g., 'request', 'response', 'fault') and each source list
(commonPolicyList, apiPolicyList) with memoized values using useMemo, and
include relevant dependencies like commonPolicyList, apiPolicyList, gatewayType
and selectedCategories so the cache invalidates correctly; update places that
read those filtered lists to use the memoized variables.
- Around line 149-152: The current equality check comparing nextSelection and
prev by index can miss cases where they contain the same elements in a different
order; update the logic around the array comparison (the block that checks
nextSelection.length !== prev.length || nextSelection.some(...)) to perform an
order-insensitive comparison instead—either convert both arrays to Sets and
compare sizes and that every element of one Set exists in the other, or sort
both arrays (stable, same comparator) and then compare elements; ensure you
still return nextSelection when they differ. Use the existing identifiers
nextSelection and prev to locate and replace the comparison.

In `@portals/publisher/src/main/webapp/source/src/app/data/PolicyHub.js`:
- Around line 10-13: Replace the hardcoded development URL in
DEFAULT_POLICY_HUB_ENDPOINT with a non-sensitive placeholder or null (e.g., a
clearly marked placeholder string or undefined) and update getPolicyHubEndpoint
to detect the missing config and either throw an error or log a warning
instructing the deployer to set the real endpoint; specifically change the
DEFAULT_POLICY_HUB_ENDPOINT constant and add validation in the
getPolicyHubEndpoint function to fail fast (throw or console.warn) when no
endpoint is configured so no internal/staging URL is used by default.
- Around line 309-328: The pagination loop in listAllPolicies can run
indefinitely if the API returns a wrong/huge count; add a safeguard by
introducing a max iteration/pages guard (e.g., MAX_ITERATIONS or MAX_PAGES) and
an iterations counter, increment it each loop and break (or throw a descriptive
error) if exceeded; update references in listAllPolicies (limit, offset, count,
policies, and the call to listPolicies) so the loop stops after that cap to
prevent excessive requests.
- Around line 265-294: The request function currently calls fetch without a
timeout; modify request (the async function named request) to use an
AbortController: create a controller, pass controller.signal into fetch, start a
timer (e.g., from a configurable timeout value or a sensible default) that calls
controller.abort() when elapsed, and clear the timer after fetch completes;
handle aborts by catching the thrown DOMException/AbortError and rethrowing a
clear Error (e.g., "Policy Hub request timed out") while preserving existing
error handling for non-OK responses; ensure headers/body/params usage remains
unchanged and the abort controller is cleaned up to avoid leaks.
- Around line 94-115: The recursive traversals in findAttributeArray (and
similarly in findSchemaObject) need a recursion depth limit to avoid stack
overflows on malformed inputs; add an optional depth parameter (or use a local
MAX_DEPTH constant) and on each recursive call decrement/check it, returning
null when depth is exceeded, and update every recursive invocation inside
findAttributeArray and findSchemaObject to pass the decremented depth so
traversal stops after the limit; ensure the default behavior uses a sensible
MAX_DEPTH (e.g., 50) so existing behavior is preserved for normal inputs.
- Around line 16-17: The module-level Maps policyDefinitionCache and
policySpecCache are unbounded and risk memory growth; add a mitigation by either
replacing them with a bounded LRU implementation (e.g., a small LRU class used
for policyDefinitionCache and policySpecCache) or, minimally, add and export a
clearCaches function that calls policyDefinitionCache.clear() and
policySpecCache.clear(); update the module's default export (and any referenced
functions that assume caches) to include clearCaches so callers can purge
caches, and ensure any places noted around lines 354-384 use the new cache API
consistently.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@portals/admin/src/main/webapp/site/public/locales/fr.json`:
- Line 160: The fr.json locale contains untranslated English strings for the new
Platform Gateway flow (e.g. the key
"AdminPages.Gateways.table.header.gatewayStatus"); update these entries by
replacing the English values with correct French translations for all new
Platform Gateway keys in fr.json (including the other untranslated entries noted
in the review), ensure JSON remains valid (proper quoting/escaping) and keep the
keys unchanged so the UI picks up the translations.

---

Nitpick comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/APICreateRoutes.jsx`:
- Around line 78-89: The two identical entries in gatewayDetails (the key
CONSTS.GATEWAY_TYPE.apiPlatform and the PlatformGateway key) exist intentionally
because the backend can return either 'api-platform' or 'PlatformGateway' (see
MetaData.jsx); add a concise inline comment above these entries explaining that
both keys map to the same gateway value to handle legacy/alternate backend
responses, referencing CONSTS.GATEWAY_TYPE.apiPlatform, PlatformGateway and
gatewayDetails so future maintainers understand why both entries are present.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@portals/publisher/src/main/webapp/source/src/app/data/PolicyHub.js`:
- Around line 12-14: The constant DEFAULT_POLICY_HUB_ENDPOINT in PolicyHub.js is
a hardcoded Choreo dev URL that may leak into production; change the code that
reads settings.policyHub.endpoint to fail fast or at least warn instead of
silently using DEFAULT_POLICY_HUB_ENDPOINT: update the logic around
DEFAULT_POLICY_HUB_ENDPOINT and the settings lookup (policyHub.endpoint) to
throw an explicit error when no endpoint is configured (or emit a clear runtime
warning if you prefer), and document this behavior so deployments must provide
policyHub.endpoint; ensure the change references DEFAULT_POLICY_HUB_ENDPOINT and
the settings.policyHub.endpoint usage so reviewers can find and update all call
sites.

---

Nitpick comments:
In `@portals/publisher/src/main/webapp/source/src/app/data/PolicyHub.js`:
- Around line 267-296: The request function can hang because fetch has no
timeout; modify request (in PolicyHub.js) to use an AbortController with a
configurable timeout (e.g., default 10s) so the fetch is aborted after the timer
elapses: create an AbortController, pass its signal into fetch options, set a
setTimeout to call controller.abort() and clear the timeout on success, and
ensure the thrown error on abort is handled/annotated (preserve existing error
handling for response.ok). Keep the existing params/headers/body behavior and
add an optional timeout argument to request or use an internal constant.
- Around line 18-19: The in-memory maps policyDefinitionCache and
policySpecCache grow unbounded; introduce eviction by replacing direct Map usage
with a capped/TTL-backed cache wrapper (e.g., an LRU or TTL policy) and update
all access points to use the new wrapper’s get/set/delete methods; specifically,
create a small cache utility (used by policyDefinitionCache and policySpecCache)
that enforces a maxEntries and/or timeToLive, evicts oldest or expired entries
on put/get, and exposes the same lookup/insert semantics so functions that
reference policyDefinitionCache and policySpecCache can remain unchanged except
for using the new cache instance.